Libris Britannia 4/science library(b).zip/science library(b)/INFO/DOSTIPS4.ZIP/DOSSCTY.TXT

Text File | 1986-06-28 | 16KB | 314 lines

                        Security Concerns
       (PC Magazine Vol 5 No 1 January 14, 1986 PC Tutor)

     One of the consequences of the PC's open architecture is that
password security is very difficult to implement.  Many corporate PC
users live by a simple rule: If the file contains confidential
information, it must be stored on a disk and kept in a locked desk.
Typically, some paranoia accompanies this rule, such as requiring
users to turn off the PCs after using a confidential file so nobody
could DEBUG the data out of memory.
     If your database is much too big and complex for disks, another
solution is Iomega's Bernoulli Box.  The standard configuration comes
with two 10-megabyte drives with removable cartridges.  Bernoulli Box
access is faster than XT hard disk access, and the cartridges are more
reliable, since they cannot crash.  Cartridges are removable, easy to
back up, and they can be kept in a safe place when not in use.
     If you have multiple users of a system, however, people may find
it inconvenient to fetch a disk or Bernoulli Box cartridge whenever
they need to use the database.  You could, therefore, replace the XT
hard disk with another that is not quite so IBM compatible.  Such
third-party hard disks generally require a driver program in a
CONFIG.SYS file during boot time.  Thus, authorized users could be
given a copy of the properly configured boot disk.  If the machine is
turned off after each use, the hard disk could not be accessed without
the right driver program.  (The Bernoulli Box without the boot option
also needs a driver file, but if you left the cartridge itself in the
machine, someone could walk away with it.)
     Another possibility is to use an encryption and decryption
program.  After using a confidential file, you'd run the encryption
program with a password, which scrambles up the file.  When you wanted
to use it again, you'd run the decryption program with the same
password to unscramble it.  Low-cost encryption programs are readily
available.  Such encryption schemes are very difficult to break without
knowing the password, even if you should gain access to the decryption
program.  Moreover, if someone maliciously tries to scramble up the
encrypted program, it should be obvious when it's decrypted.  To
protect against such contingencies, you should be keeping disk backups
anyway.
     Preventing someone from using your PC entirely is a little more
difficult.  One solutin is a lock switch on the machine, something
like the keyboard lock on the PC AT.  There are commercial locks that
attach to the on/off switch on the PC and XT.
     Putting a password program in an AUTOEXEC.BAT program does not
work at all, since the user can break out of the batch file before the
program is even executed.  You can put the password program in a dummy
device driver.  Device drivers are loaded early in the boot process,
and it would not be possible to break out of it.  However, someone can
come along with a bootable disk and boot the machine from drive A:.
DO NOT disable drive A: to prevent this.
     You can, however, install a password program that cannot be
circumvented by a drive A: boot.  This program has to be executed
before the PC even attempts to boot.  Here's how it works.
     When the PC is first turned on, it executes a "power-on self test"
(POST) program coded in the PC's ROM BIOS.  This program initializes
the system, checks memory and ultimately boots the operating system
from a disk or hard disk.  Before the boot, however, the POST program
checks memory locations between addresses C8000h and F4000h for the
presence of additional read-only memory (ROM) programs.  Generally,
these programs are used to perform some extra system initialization
before the PC is booted.  In fact, the extra BIOS for the XT hard disk
is at address C8000h.  You would have to program a small password
routine somewhere in that memory space where it wouldn't conflict with
anything else.  Moveover, the program must stay in memory when the PC
is turned off.
     Getting the password program encoded in ROM is a bit extreme.  An
easier approach is to code it into random access memory on a CMOS RAM
memory board with battery backup.  (Tecmar, for instances, sells a 32K
CMOS RAM board through its Scientific Solutions subsidiary.)  CMOS RAM
uses very little power -- almost none at all while inactive -- so a
rechargeable battery backup should last for many months.
     The board's memory address would be set up to begin at D0000h,
d*000h, E0000h or E8000h.  The program must use a special format, which
is explained in the ROM BIOS section of the PC or XT Tech Reference
manuals under the heading "Adapter Cards with System-Accessible ROM
Modules."  The code must start off with a 55h and AAh, to tell the
BIOS that it is executable.  The third byte is the number of 512-byte
blocks in the program -- probably 1 for a simple password routine.
The program itself begins at the fourth byte, and it must return to
the BIOS with a far return.  You should write the program in assembly
language, and you may not use any DOS calls (Interrupts 20h and up)
because DOS will not be loaded when the program runs.  You may,
however, use all the BIOS resources for the keyboard and display.
     The ROM BIOS does a check-sum of the bytes of the program and
gives you a terse "ROM" message if they don't add up to zero ignoring
overflow above 256.  So, you're going to have to add up all the bytes
in your program, take the negative, and put that byte somewhere in the
file.  The assembly language program below can get you started.  (This
program has NOT been tested with a CMOS memory board, but it follows
all the rules and should work.)  The use of the word "password" for a
password is obviously a very poor choice and is used here only for
illustration.  Note that there is no prompt for the password.  Not are
the characters echoed to the display.  To someone who doesn't know
that you've installed this, it will appear as if the machine is broken
and will not boot.  Note also the nasty CLI and HLT code if a wrong
letter is typed.  This will disable interrupts and halt the
microprocessor, so even a "three-key" restart won't work.  Any
tamperer would have to turn the machine off and back on to try again.
You could omit the CLI to allow use of Ctrl-Alt-Del if a mismatch
occurs.  You can get more elaborate and allow three retries and
asterisk echoes and stuff like that.  For testing the guts of the
program, you may want to set it up first as a regular .COM file and
alter it for the ROM format after it's working.
     Once you've MASMed, LINKed and EXE2BINed the ROM format program,
you must add up all the bytes in it and find the two's complement (the
byte that added to the rest will make zero, ignoring overflow above
256).  You could write a BASIC program to help out with this
calculation.  Put the byte in after the CHECK label and reassemble.
     When you're ready, load the final file into DEBUG and move it to
the CMOS RAM board with the command line:  M 100 L 200 D000:0
Reboot to test it out.  If it doesn't seem to work, you'll have to
disable the memory board via a DIP switch and try to figure out what
the problem is.  Debugging pre-boot ROM routines usually requires
specialized tools and is not easy on a regular PC or XT.
     If this project sounds like the ultimate headache, there is at
least one commercially available board (from International Electronic
Technology Corp.) that does virtually the same thing.  You create an
8-digit numeric password by setting DIP switches on the board.
     Even though the board method seems pretty good, it is certainly
not completely tamperproof.  Anyone encountering a PC reluctant to
boot could simply open the PC, remove the offending board and restart
the machine.  You may want to bolt the case down with fancy screws
that require a special screwdriver.  And don't forget to protect
yourself agains the ultimate security problem -- the one where you
come to work in the morning and the PC is not there at all.

;  PASSWORD.ASM for CMOS RAM
;
CSEG     Segment
   Assume     CS:CSEG
Marker   db   55h, 0AAh, 1

Entry    Proc Far
   Mov   BX,Offset Pword - 1
   Mov   CX,8

Looper:  Sub  AH,AH
   Int   16h
   Inc   BX
   Cmp   AL,CS:[BX]
   Jnz   NoGood
   Loop  Looper
   Ret

NoGood:  Cli
   Hlt
Entry    EndP

Pword    db   'password'
Check    db   ?
   db  (512-($-Marker)) dup (0)

CSEG     Ends
   End

-----------------------------------------------------------------
                       Easy Data Security
       (PC Magazine Vol 5 No 7 Apr 15, 1986 User-to-User)

     There's a simple but effective method for keeping data on a
shared hard disk secure.  It won't fool a real expert, but it does
screen most others out.
     The trick is to use the ASCII character 255 either as part of a
subdirectory name or a filename.  To create a subdirectory that few,
if any, users will be able to access, type:

MD\SECRET

but add a CHR$(255) after the final T in SECRET by holding down the
Alt key, typing 255 on the number pad, and then releasing the Alt key.
After this has been done, all a snooping user will get by typing
CD\SECRET is a frustrating "Invalid directory" message.  You can also
use this trick with filenames, either by putting the CHR$(255) in the
middle of the file or at the end.  In this case, users will get a
"File not found" message.
     Editor's Note:  This trick will fool most naive users who either
won't see the CHR$(255) blank if it's at the end of a subdirectory or
filename, or who will assume it's a conventional CHR$(32) space if it
appears elsewhere in the name.  Not only will unauthorized users not
be able to type the contents of such secured files, they also won't
be able to copy or delete them.

-----------------------------------------------------------------
                      Sneaky File Security
      (PC Magazine Vol 5 No 11 June 10, 1986 User-to-User)

     While various programs on the market can encrypt DOS data files
that contain sensitive information, there is one big limitation to all
of them -- the user must manually call up the program, specify which
file to encrypt, and then enter some sort of password.  Pity the poor
soul who forgets the password!
     It would make more sense to build the encryption directly into
the program.  One simple method would be to add 128 to the ASCII value
of each character in the file, but that requires extra code every time
the program reads or writes.  Worse, it would be painfully slow when
processing many records.
     A better way is to write a Ctrl-Z at the beginning of the file --
before any data is stored.  This prevents unauthorized users from
snooping with the TYPE command or using the COPY command to send the
file to a printer on the screen.  But it lets you copy the file to
another disk.  For a nonprogrammer, the only way to get the data would
be with a sector-reading utility like Norton's Utilities.
     The HIDDEN.BAS program below creates and reads a simple name-and-
address file, while demonstrating the technique described.  The only
compromise is the space lost to the first record.  Note that this
method will also work when writing a sequential file; however, it
must be read as a random file using the FIELD and GET statements.

100 'HIDDEN.BAS -- Reads/writes "hidden" files
110 'First, create "hidden" file
120 OPEN "NAMES" AS #1 LEN=80
130 FIELD #1,22 AS NAM$,22 AS STREET$,22 AS CITY$,14 AS PHONE$
140 LSET NAM$="Access Denied"+CHR$(26):PUT #1
150 FOR X=1 TO 9
160 LSET NAM$    = "Smith, John"
170 LSET STREET$ = "129 East 14th St. #"+MKI$(X+48)
180 LSET CITY$   = "New York, N.Y. 10028"
190 LSET PHONE$  = "[phone]"
200 PRINT "Writing record #";RIGHT$(STR$(X),1)
210 PUT #1:NEXT:CLOSE
220 'Show you can still read from "hidden" file
230 INPUT "Which record do you want to read (1-9): ",F$
240 IF VAL(F$)<1 or VAL(F$)>9 THEN BEEP:GOTO 230
250 OPEN "NAMES" AS #1 LEN=80
260 FIELD #1,22 AS NAM$,22 AS STREET$,22 AS CITY$,14 AS PHONE$
270 GET #1,VAL(F$)+1
280 PRINT NAM$:PRINT STREET$:PRINT CITY$:PRINT PHONE$
290 CLOSE

Editor's Note:  Software manufacturers have been using a variation of
this trick for years, putting a copyright notice or a screen full of
text at the beginning of a .COM or .EXE file, followed immediately by
a Ctrl-Z end-of-file marker.  If users try to type the file, all they
get is the message.
     The trick in HIDDEN.BAS works only with naive users.  The first
thing a typical user would do on seeing an "Access Denied" message is
look at the contents using DEBUG's (D)ump command.  Or he would write
a small program to read the file byte by byte:

100 'Random file reader
110 OPEN "NAMES" as #1 LEN=1
120 FIELD 1,1 AS A$
130 FOR A=1 to LOF(1)
140 GET 1,A:PRINT A$;
150 NEXT

Obviously, you should substitute the name of the file in question for
NAMES in line 110.  And you can speed things up considerably by
increasing the LEN record length beyond one character.
     Incidentally, while adding 128 (or any other value from 1 to 128)
to each character in a file is a very unsophisticated security device,
it will also keep casual snoopers away and is simple to do.  To try
this with the NAMES file created by the HIDDEN.BAS program, simply run
the following program:

100 'Trivial encryptor
110 OPEN "NAMES" AS #1 LEN=1
120 OPEN "NEWNAMES" AS #2 LEN=1
130 FIELD 1,1 AS A$
140 FIELD 2,1 AS B$
150 FOR A=1 to LOF(1)
160 GET 1,A
170 LSET B$=CHR$(ASC(A$) XOR 128)
180 PUT #2,A
190 NEXT:CLOSE

(Be sure the NAMES file you created in the previous example is on the
same disk as this trivial encryptor, or it won't have anything to
encrypt.)
     If a user types the contents of the NEWNAMES file, all he'll see
is meaningless "high-bit" characters.  To unscramble the NEWNAMES file,
just run this program:

100 'Trivial decryptor
110 OPEN "NEWNAMES" AS #1 LEN=1
120 FIELD 1,1 as A$
130 FOR A=1 to LOF(1)
140 GET 1,A
150 PRINT CHR$(ASC(A$) XOR 128);
160 NEXT:CLOSE

     Instead of using the 128 in the two previous programs, you can
substitute any number from 1 to 127, but make sure you do it in both
the encryptor and decryptor programs.  It's easy to beat such a trivial
transposition encryption scheme.  To do so, just look at the contents
with the DOS TYPE or DEBUG Dump commands.  Random access files pad out
unused fields with space characters (CHR$(32)).  The encryptor file
above will uniformly change them to something else.  In this example,
it will be an a with a dot over it (CHR$(160), since 32 + 128 = 160).
It's easy to see these characters padding out fields of different
sizes.  Once you find the "encryptor" space character, subtract 32
from it and XOR all the characters with the value of the difference.

-----------------------------------------------------------------
                         Security Leaks
      (PC Magazine Vol 5 No 11 June 10, 1986 User-to-User)

     A person used the encryption feature of SuperKey to "keep safe"
sensitive correspondence on a hard disk.  In checking these safety
measures, the results were enlightening.
     In this instance, a well-known word processor was used that
produces .BAK files with each new or changed document, and the .BAK
files were erased.  After a couple of minutes with Norton Utilities,
it was possible to unerase these unprotected backup files.  Now the
person uses Norton's FileWipe program to complete erase backup files
or encrypts them before erasing.
     However, in addition to the visible .BAK files, this particular
word processor produced several working files (with .$$$ and .@@@
extensions).  Therefore, the person has to use Norton Utilities to
unerase the working files and then FileWipe or encrypt them.
     The moral is that just encrypting the working file is not enough.
Make sure all copies of the file are either encrypted or erased with a
program that will prevent them from being recovered.